1. Field of the Invention
The field of invention relates generally to a computerized architecture for facilitating revenue and authorization management.
2. Description of the Related Art
Large carriers are making a significant push to reduce the number of customer systems. Furthermore, carrier consolidation often leads to consolidation of infrastructures and system selection is frequently based on the ability to host all customers on a single system
A solution is required that offers a number of significant benefits over today's solutions such as ability to address the high-value authorization space regardless of who owns it; improved integration with CRM systems; improved rating flexibility; improved adaptability for vertical markets; cost-effective continuous availability; simplified load-balancing and capacity planning; and multiple deployment options including the use of commodity hardware. A strategy for site-level disaster resilience is also required.
Authorization takes place before and during the event. Its purpose is to ensure that the paying party has sufficient credit to cover the cost of the event. Since the authorization must be completed before the transaction can proceed, latency is critical, as is the availability of the system. Authorization may involve a reservation element. An example of an authorization without reservation would be ‘has the customer bought unlimited access to music downloads for this month’, and authorization/reservation examples include credit card style authorization and requests such as ‘confirm and reserve that the customer has the funds for a 100 MByte content download’.
It has often been said that once a wireless account can be used to pay for things other than communication services, it starts to look more like a debit card (pre-pay) or credit card (post-pay). There are a number of issues which would need to be addressed to make this vision a reality such as creating an infrastructure to allow the device to communicate with the merchant's terminal. An authorization model is desirable because it limits the credit exposure of the card issuer; guarantees payment to the merchant; and limits fraudulent use.
The best revenue management systems do a good job of being available when they are planned to be. There are various hardware and software fail-over techniques which improve the availability of the system. For example most billing systems are supported by a number of HA technologies including:                Cold database standby products such as Veritas Cluster Server.        Hot database standby as provided within Oracle 9i real application clusters.        Log shipping/delayed log application techniques to protect against database corruption.        Mirrored SAN or NFS attached storage with integral duplicated battery backed cache and controllers supported by replicated storage interconnect infrastructure.        Replicated application servers.        Reliable messaging technologies and/or application messaging that does not lose traffic (e.g. events).        Replicated network infrastructure.        
Systems using such technologies typically achieve 99.9% availability and can approach 99.99% availability excluding planned maintenance. Availability of 99.99% equates to around 1 hour of unplanned downtime each year.
It should be noted, however, that the cost of providing this improved availability is significant given the large standby machines used to provide backup database support. The incremental software license costs are also very significant, and may be of the similar order to the hardware costs.
Where today's solutions fail to deliver the availability required is when patches or upgrades are taken into account. In a typical year, it may be assumed that one upgrade and a number of maintenance patches (say 10) to the system may occur. If we assume 1 hour of downtime for each patch and 8 hours for the upgrade, we have a total planned downtime of 18 hours. In practice, however, these figures may be very optimistic—upgrades requiring database schema updates to database centric billing systems can take 24 hours or more. When combined with the unplanned downtime, we have a combined availability of 99.8%, some way from the “five 9s” of networks which allows for 5 minutes of downtime per year. Capacity upgrades may introduce significant additional downtime. And, the cost for fail-over machines is expensive. Traditional approaches may increase the cost by factor of four to ten times for each ‘nine’ added to the availability figure.
Additionally most monolithic systems do not fail gracefully—in many critical failures the whole system is unavailable. Therefore the effective downtime as perceived by the business and the associated costs will be much higher for a system with an ‘all-or-nothing’ availability profile rather than a system that under failure may degrade gracefully making only some functions or part of the consumer base available.
Raw throughput is only one measure of capacity. Telecoms require a latency of less than 100 ms for pre-event authorization to ensure that call set-up can be completed in a timely fashion. While the best revenue management systems have now reached sub 200 ms for significant volumes, there is still work to do.
Network-based solutions have come from the pre-pay world and correspondingly have their strengths in pre- and mid-event authorization, rather than post-event accounting. They are strong on availability and latency, but weak on functionality. The functionality provided by network-based solutions is rudimentary when compared with that of a revenue management system. A network-based solution assumes that all services go through a single network (at least in the authorization path).
Hybrid solutions involve an integration of a revenue management system with a network-based solution. In some respects these solutions offer the best of both worlds, especially when the services are limited to telecom services. However, when higher value services are offered, the operator is exposed to increased credit risk or inability to offer service when the revenue management system is unavailable.
None of the existing solutions successfully meet all of the requirements of relationship-centric authorization. While incremental development could evolve prior art solutions to address their limitations, it will be a costly and time-consuming exercise. Furthermore, none of today's solutions deliver the anticipated functionality, availability and throughput for these applications.